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Intellectual Property Rights 



IPRs essential or potentially essential to the present document may have been declared to ETSI. The information 
pertaining to these essential IPRs, if any, is publicly available for ETSI members and non-members, and can be found 
in ETSI SR 000 314: "Intellectual Property Rights (IPRs); Essential, or potentially Essential, IPRs notified to ETSI in 
respect of ETSI standards", which is available from the ETSI Secretariat. Latest updates are available on the ETSI Web 
server ( http://webapp.etsi.org/IPR/home.asp ). 

Pursuant to the ETSI IPR Policy, no investigation, including IPR searches, has been carried out by ETSI. No guarantee 
can be given as to the existence of other IPRs not referenced in ETSI SR 000 314 (or the updates on the ETSI Web 
server) which are, or may be, or may become, essential to the present document. 



Foreword 

This Technical Specification (TS) has been produced by ETSI Technical Committee Access and Terminals (AT). 

The present document is part 26, sub-part 1 of a multi-part deliverable. Full details of the entire series can be found in 
part 1 [28]. 



Introduction 



To evaluate conformance of a particular implementation, it is necessary to have a statement of which capabilities and 
options have been implemented for a telecommunication specification. Such a statement is called an Implementation 
Conformance Statement (ICS). 
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Scope 



The present document provides the Protocol Implementation Conformance Statement (PICS) proforma for the 
Network-based Call Signalling, Dynamic Quality of Service, Provisioning and Security protocols for the IPCablecom 
(packet-based multimedia communication) system defined in TS 101 909-3 [1], TS 101 909-4 [2], TS 101 909-5 [3], 
TS 101 909-6 [4], TS 101 909-7 [5], TS 101 909-8 [6], TS 101 909-9 [7], TS 101 909-11 [8], in compliance with the 
relevant requirements specified in those specifications and in accordance with the relevant guidance given in 
ISO/IEC 9646-7 [18]. 

The supplier of a protocol implementation which is claimed to conform to is required to complete a copy of the PICS 
proforma provided in annex A of the present document and is required to provide the information necessary to identify 
both the supplier and the implementation. 
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Definitions and abbreviations 



3.1 



Definitions 



For the purposes of the present document, the terms and definitions defined in TS 101 909-3 [1], TS 101 909-4 [2], 
TS 101 909-5 [3], TS 101 909-6 [4], TS 101 909-7 [5], TS 101 909-8 [6], TS 101 909-9 [7], TS 101 909-11 [8], 
ISO/IEC 9646-1 [17] and ISO/IEC 9646-7 [18] and the following apply: 

ICS proforma: document, in the form of a questionnaire, which when completed for an implementation or system 
becomes a PICS 

Implementation Conformance Statement (ICS): statement made by the supplier of an implementation or system 
claimed to conform to a given specification, stating which capabilities have been implemented 

NOTE: The PICS can take several forms: protocol PICS, profile PICS, profile specific PICS, information object 
PICS, etc. 

Protocol ICS (PICS): ICS for an implementation or system claimed to conform to a given protocol specification 



3.2 



Abbreviations 



For the purposes of the present document, the following abbreviations apply: 

AALN Analogue Access Line endpoint Naming 

ANSam modified answer tone 

bz busy tone 

cf congestion tone 

dl dial tone 

DQoS Dynamic Quality of Service 

E-MTA Embedded MTA 

FQDNs Fully Qualified Domain Names 

ft fax tone 

ICS Implementation Conformance Statement 

IUT Implementation Under Test 

Id Long duration connection 

It line treatment 

ma media start 

MFPB Multi Frequency Push Button 

MIB Management Information Base 

mt modem tone 

MTA Multimedia Terminal Adapter 

mwi message waiting indicator 

NCS Network-based Call Signalling protocol 

of operation failure 

ot off-hook warning tone 

pd pulse encoding duration 

PDU Protocol Data Unit 

PICS Protocol Implementation Conformance Statement 

pr pulse period encoding duration 

ro reorder tone 

rs ringsplash 

rt ring back tone 

SCS System Conformance Statement 

si stutter dial tone 

SUT System Under Test 

TDD Telecom Devices for the Deaf tones 

TGS Ticket Granting Server 

TO timeout 

wtl call waiting tone 1 
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Overview 



The TS 101 909 specifications are not a series of individual standards that were just glued together to make a solution; 
they are a cohesive set of interwoven specifications that jointly evolved to enable the IPCablecom implementations to 
interwork as a cohesive end-to-end system. They are entirely based on cable operator needs and requirements. Any 
changes made to one part have to be done in concert with work being done in other parts. These must be closely 
coordinated to ensure the elements interface together properly. 

For all of the sections of a given specification, there is a history of evolution and reasoning behind the development of 
PacketCable™ and subsequently IPCablecom.The present document relates to the set of base standards as defined in the 
TS 101 909 series, there is no single base standard that covers the requirements of the E-MTA in its entirety. Figure 1 
illustrates the set of TS 101 909 series base standards that have been referred to in order to evaluate an E-MTA protocol 
implementation, for the purpose of developing the present document. 

PICS Statements per specification 



1000 n 



100- 



10 



V 




Base specifications 



□ Pt. 


3 Audio Codec 


■ Pt. 


4NCS 


□ Pt. 


5DQoS 


□ Pt. 


6 Provisioning 


■ Pt. 


7MIB 


□ Pt. 


8 MTA_MIB 


■ Pt. 


9 SIG_MIB 


□ Pt.11 Security 



Figure 1 : Base specifications relevant to the E-MTA 



5 Conformance to this PICS proforma specification 

If it claims to conform to the present document, the actual PICS proforma to be filled in by a supplier shall be 
technically equivalent to the text of the PICS proforma given in annex A, and shall preserve the numbering/naming and 
ordering of the proforma items. 

A PICS which conforms to the present document shall be a conforming PICS proforma completed in accordance with 
the guidance for completion given in clause A. 1 . 
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Annex A (normative): 

PICS proforma for TS 101 909 IPCablecom series specific 

to embedded multimedia terminal adapter 



Notwithstanding the provisions of the copyright clause related to the text of the present document, ETSI grants that 
users of the present document may freely reproduce the PICS proforma in this annex so that it can be used for its 
intended purposes and may further publish the completed PICS. 



A.1 Guidance for completing the PICS proforma 



A.1 .1 Purposes and structure 



The purpose of this PICS proforma is to provide a mechanism whereby a supplier of an implementation of the 
requirements defined in the ETSI IPCablecom (TS 101 909) series may provide information about the implementation 
in a standardized manner. 

The PICS proforma is subdivided into clauses for the following categories of information: 

guidance for completing the PICS proforma; 

identification of the implementation; 

identification of the protocol; 

global statement of conformance; 

audio codec implementation; 

network-based call signalling protocol implementation; 

dynamic quality of service implementation; 

multimedia terminal adapter provisioning implementation; 

management information base implementation; 

implementation of security mechanisms. 

A.1 .2 Abbreviations and conventions 

The PICS proforma contained in this annex is comprised of information in tabular form in accordance with the 
guidelines presented in ISO/IEC 9646-7 [18]. 

Item column 

The item column contains a qualified number which identifies the item in the table. 

Item description column 

The item description column describes in free text each respective item (for example parameters, timers, etc.). It 
implicitly means "is < item description > supported by the implementation?". 
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Status column 

The following notations, defined in ISO/IEC 9646-7 [18], are used for the status column: 

M mandatory - the capability is required to be supported; 

O indicates an optional requirement in TS 101 909. However, only sending of the parameter/message 

is optional. When the parameter/message is received an ETSI IPCablecom compliant E-MTA shall 
act upon the parameter/message in accordance with the procedures as described in the main body 
of the present document; 

N/A not applicable - in the given context, it is impossible to use the capability; 

X prohibited (excluded) - there is a requirement not to use this capability in the given context; 

Ot.i qualified optional - for mutually exclusive or selectable options from a set. "i" is an integer which 

identifies a unique group of related optional items in the table numbered t and the logic of their 
selection which is defined immediately following the table; 

Ct.i conditional - the requirement on the capability ("m", "o", "x" or "n/a") depends on the support of 

other optional or conditional items, "i" is an integer identifying a unique conditional status in the 
table numbered t, expression which is defined immediately following the table. 

Support column 

The support column shall be filled in by the supplier of the implementation. The following common notations, defined 
in ISO/IEC 9646-7 [18], are used for the support column: 

Y or y supported by the implementation; 

N or n not supported by the implementation; 

N/A, n/a or no answer required (allowed only if the status is n/a, directly or after evaluation of a conditional 

status). 

It is also possible to provide a comment to an answer in the space provided at the bottom of the table. 

NOTE: As stated in ISO/IEC 9646-7 [18], support for a received PDU requires the ability to parse all valid 
parameters of that PDU. Supporting a PDU while having no ability to parse a valid parameter is non- 
conformant. Support for a parameter on a PDU means that the semantics of that parameter are supported. 

Values allowed 

Notes describe the content of the field, when only restricted values are supported, for sent message. 

References to items 

For each possible item answer (answer in the support column) within the PICS proforma a unique reference exists, 
used, for example, in the conditional expressions. It is defined as the table identifier, followed by a solidus character "/", 
followed by the item number in the table. 

EXAMPLE: A.5/4 is the reference to the answer of item 4 in table 5 of annex A. 

Prerequisite line 

A prerequisite line takes the form: Prerequisite: < predicate >. 

A prerequisite line after a clause or table title indicates that the whole clause or the whole table is not required to be 
completed if the predicate is FALSE. 
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A.1 .3 Instructions for completing the PICS proforma 

The supplier of the implementation shall complete the PICS proforma in each of the spaces provided. In particular, an 
explicit answer shall be entered, in each of the support or supported column boxes provided, using the notation 
described in clause A. 1 .2. 

If necessary, the supplier may provide additional comments in space at the bottom of the tables, or separately on sheets 
of paper. 

More detailed instructions are given at the beginning of the different clauses of the PICS proforma. 



A.2 Identification of the implementation 

Identification of the Implementation Under Test (IUT) and the system in which it resides (the System Under Test 
(SUT)) should be filled in so as to provide as much detail as possible regarding version numbers and configuration 
options. 

The product supplier information and terminal information should both be filled in if they are different. 

A person who can answer queries regarding information supplied in the PICS should be named as the contact person. 

A.2.1 Date of the statement 



A.2. 2 Implementation Under Test (IUT) identification 

IUT name: 



IUT version: 

A.2.3 System Under Test (SUT) identification 

SUT name: 

Hardware configuration: 



Operating system: 
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A.2.4 Product supplier 



Name: 



Address: 



Telephone number: 



Facsimile number: 



E-mail address: 



Additional information: 



A.2.5 PICS contact person 

(A person to contact if there are any queries concerning the content of the PICS) 

Name: 



Telephone number: 



Facsimile number: 



E-mail address: 



Additional information: 
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A.3 PICS/System Conformance Statement (SCS) 

Provide the relationship of the PICS with the SCS for the system. 

A. 4 Identification of the protocols to the interfaces on the 
E-MTA 

The PICS proforma applies to the following standards: 

ETSI TS 101 909-3 (VI. 1.1): "Access and Terminals (AT); Digital Broadband Cable Access to the Public 
Telecommunications Network; IP Multimedia Time Critical Services; Part 3: Audio Codec Requirements for the 
Provision of Bi-Directional Audio Service over Cable Television Networks using Cable Modems". 

ETSI TS 101 909-4 (Vl.2.2): "Digital Broadband Cable Access to the Public Telecommunications Network; IP 
Multimedia Time Critical Services; Part 4: Network Call Signalling Protocol" 

ETSI TS 101 909-5 (VI. 1.1): "Access and Terminals (AT); Digital Broadband Cable Access to the Public 
Telecommunications Network; IP Multimedia Time Critical Services; Part 5: Dynamic Quality of Service for the 
Provision of Real Time Services over Cable Television Networks using Cable Modems". 

ETSI TS 101 909-6 (VI. 1.1): "Access and Terminals (AT); Digital Broadband Cable Access to the Public 
Telecommunications Network; IP Multimedia Time Critical Services; Part 6: Media Terminal Adapter (MTA) device 
provisioning" 

ETSI TS 101 909-7 (VI. 1.1): "Access and Terminals (AT); Digital Broadband Cable Access to the Public 
Telecommunications Network; IP Multimedia Time Critical Services; Part 7: Management Information Base (MIB) 
Framework". 

ETSI TS 101 909-8 (VI. 1.1): "Access and Terminals (AT); Digital Broadband Cable Access to the Public 
Telecommunications Network; IP Multimedia Time Critical Services; Part 8: Media Terminal Adapter (MTA) 
Management Information Base (MIB)". 

ETSI TS 101 909-9 (VI. 1.1): "Access and Terminals (AT); Digital Broadband Cable Access to the Public 
Telecommunications Network; IP Multimedia Time Critical Services; Part 9: Network Call Signalling (NCS) MIB 
Requirements". 

ETSI TS 101 909-1 1 (Vl.2.1): "Digital Broadband Cable Access to the Public Telecommunications Network; IP 
Multimedia Time Critical Services; Part 11: Security". 



A.5 Global statement of conformance 

Are all mandatory capabilities implemented? (Yes/No). 

NOTE: Answering "No" to this question indicates non-conformance to the protocol specification. Non-supported 
mandatory capabilities are to be identified in the PICS, with an explanation of why the implementation is 
non-conforming, on pages attached to the PICS proforma. 
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A.6 Audio Codec 



Table A.1 : Audio Codec 



Item 


Requirement 


Reference 


Status 


Support 


AC 1 


Does the E-MTA support a G.71 1 codec? 


5 [11 


M 




AC 2 


Does the E-MTA support a G.728 codec? 


5.1 [1] 


O 




AC_3 


Does the E-MTA support a G.729, annex E 
codec? 


5.1 [1] 


O 




AC_4 


Does the E-MTA successfully pass DTMF tone 
transmissions? 


4.1 [1] 


M 




AC_5 


Are your specified codecs capable of 
transparently passing DTMF tones in-band? 


4.1 [1] 


M 




AC 6 


Does the E-MTA detect fax/modem signals? 


4.2 [1] 


M 




AC_7 


Does the E-MTA support Line echo 
cancellation? 


4.3 [1] 


M 




AC_8 


Does the E-MTA support full duplex echo 
cancellation? 


4.3 [1] 


M 




AC_9 


Is the echo canceller in compliance with 
ITU-T Recommendation G.165 [19]? 


4.3 [1] 


O 




AC_10 


Is the echo canceller in compliance with 
ITU-T Recommendation G.168 [20]? 


4.3 [1] 


O 




AC_11 


Does the E-MTA support detection of 
ITU T Recommendation V.18 [25] hearing- 
impaired tones, including V.18 annex A? 


4.5 [1] 


M 




AC_12 


Does the E-MTA support 

ITU-T Recommendation V.18 [25] annex G? 


4.5 [1] 


O 




AC_13 


Does the E-MTA support G.71 1 codec in both 
companding modes (mu-law and A-law)? 


5.1 [1] 


M 




AC_14 


Does the E-MTA support codecs encoded with 
RTPMap Parameters? 


Annex A [1] 


M 




AC_15 


Does the E-MTA support G.71 1 encoding 
using name PCMU/8000? 


Annex A [1] 


O 




AC_16 


Does the E-MTA support mapping of either the 
payload type or ASCII string representation to 
the bandwidth requirements for every defined 
Codec? 


Annex A [1] 


M 




AC_17 


Does the EMTA support mapping of RTP/AVP 
code to RSVP Flowspec (as used by DQoS)? 


Annex A [1] 


M 




Comments: 
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A.7 Network-based call signalling protocol 

Table A.2: MGCI Naming and Model Conventions supported by the E-MTA 



Item 


Requirement 


Reference 


Status 


Support 


NCS_1 


With respect to the MGCI Interface, does the 
implementation support one or more 
connections belonging to the same call? 


6.1 [2] 


O 




NCS_2 


Does the local endpoint name adhere to the 
naming rules set out in clause 6.1 .1 of 
TS101 909-4 [2]? 


6.1.1 [2] 


M 




NCS_3 


Are the individual terms of the local endpoint 
names separated by a single slash ("/", ASCII 
2F hex)? 


6.1.1 [2] 


M 




NCS_4 


Is wild-carding represented by either an 
asterisk ("*") or a dollar sign ("$") for the 
terms of the naming path? 


6.1.1 [2] 


M 




NCS_5 


If a term is wild-carded, then are all terms to 
the right of that term wild-carded as well? 


6.1.1 [2] 


M 




NCS_6 


When mixed dollar sign and asterisk 
wild-cards are used, dollar-signs are only 
allowed from the right, thus if a term had a 
dollar sign wild-card, are all terms to the right 
of the dollar sign also wild-carded using the 
dollar sign? 


6.1.1 [2] 


M 




NCS_7 


Does the end point naming contain additional 
rules apart from those that are set out in 
clause 6.1.1 ofTS101 909-4 [2]? 


6.1.1 [2] 


M 




NCS_8 


Are those additional end point naming rules 
not in conflict with those specified in 
clause 6.1.1 ofTS101 909-4 [2]? 


6.1.1 [2] 


M 




NCS_9 


Do endpoints support digit maps as defined in 
clause 6.1.5 of TS 101 909-4 [2]? 


6.1.5 [2] 


M 




NCS_10 


Does the E-MTA reject package names 
where the first or last character in a name is a 
hyphen as given in clause 6.1 .6 of 
TS 101 909-4 [2]? 


6.1.6 [2] 


M 




NCS_1 1 


Does the E-MTA support the use of an "at" 
sign (@) as a delimiter as given in 
clause 6.1.6 of TS 101 909-4 [2]? 


6.1.6 [2] 


M 




Comments: 
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Table A.3: Analogue Access Line endpoint Naming (AALN) supported by the E-MTA 



Item 


Requirement 


Reference 


Status 


Support 


NCS_12 


Do endpoints in embedded clients support 
the analogue telephone (aaln) naming 
conventions specified in clause 6.1 .1 .1 of 
TS 101 909-4 [2]? 


6.1.1.1 [2] 


M 




NCS_1 3 


Does the E-MTA local endpoint name contain 
at least one and, at most, two Terms as given 
in clause 6.1.1.1.1 ofTS101 909-4 [2]? 


6.1.1.1.1 [2] 


M 




NCSJ4 


For Terml , does E-MTA endpoint support the 
term containing "aaln"? 


6.1.1.1.1 [2] 


M 




NCS_15 


For Terml , does the E-MTA endpoint support 
the term containing a wildcard character? 


6.1.1.1.1 [2] 


M 




NCS_1 6 


For Term2, does the E-MTA endpoint contain 
a number representing the number of 
analogue access lines supported by the 
embedded client in question? 


6.1.1.1.1 [2] 


M 




NCS_1 7 


When a local endpoint name is composed of 
only one term, is this Terml ? 


6.1.1.1.1 [2] 


M 




Comments: 



Table A.4: Support of Wildcard Characters by the E-MTA 



Item 


Requirement 


Reference 


Status 


Support 


NCS_1 8 


Does the E-MTA support the use of the 
wildcard character "*" (asterix) to denote all 
connections, as given in clause 6.1 .6 of 
TS 101 909-4 [2]? 


6.1.6 [2] 


M 




NCS_1 9 


Does the E-MTA support the use of the 
wildcard character "$" (dollar sign) to denote 
a current connection, as given in clause 6.1.6 
of TS 101 909-4 [2]? 


6.1.6 [2] 


M 




Comments: 
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Table A.5: Gateway Control Functions supported by the E-MTA 



Item 


Requirement 


Reference 


Status 


Support 


NCS_20 


Does the Embedded client implement the 
MGCI as defined (clause 15 of 
TS 101 909-4 [2]), including the semantics 
specified and the message formats and 
encodings used? 


6.3 [2] 


M 




NCS_21 


Does the implementation support "network 
loopback" mode and reflect RTP packets? 


6.3 [2] 


O 




NCS_22 


Does the implementation support "network 
continuity test" mode, with internal decoding 
and re-encoding as appropriate? 


6.3 [2] 


M 




NCS_23 


Does the E-MTA not place the "network 
continuity test" audio signal on its analogue 
access line, regardless of the current 
hook-state of the analogue TE, i.e. in either 
on-hook or off-hook state? 


6.3 [2] 


M 




NCS_24 


Is the E-MTA capable of supporting new and 
existing connections for the endpoint when 
some connections are placed in "network 
loopback" or "network continuity test" mode? 


6.3 [2] 


M 




NCS_25 


Does the E-MTA support selection of one 
codec as per the "Encoding Method" 
parameter of the LocalConnectionOptions 
field in the CreateConnection message, as 
given in clause 6.3.3 of TS 101 909-4 [2]? 


6.3.3 [2] 


M 




NCS_26 


Does the E-MTA implement the value 
specified in the "Packetization Period" 
parameter of the LocalConnectionOptions 
field in the CreateConnection message, as 
given in clause 6.3.3 of TS 101 909-4 [2]? 


6.3.3 [2] 


M 




NCS_27 


Does the E-MTA implement the value 
specified in the "Silence Suppression" 
parameter of the LocalConnectionOptions 
field in the CreateConnection message, as 
given in clause 6.3.3 of TS 101 909-4 [2]? 


6.3.3 [2] 


M 




NCS_28 


If no value is specified in the "Silence 
Suppression" parameter, does the E-MTA not 
use Silence Suppression? 


6.3.3 [2] 


M 




NCS_29 


Does the E-MTA apply echo cancellation to 
the analogue line (for the specified embedded 
client) when the "Echo cancellation" 
parameter is omitted from the 
LocalConnectionOptions field in a 
CreateConnection message, as given in 
clause 6.3.3 of TS 101 909-4 [2]? 


6.3.3 [2] 


M 




NCS_30 


Is the secret (as specified in the IPCablecom 
Security specification [8]) encoded using 
base64 encoding? 


6.3.3 [2] 


M 




NCS_31 


Does the E-MTA respect the requirement to 
implement the first value in the list of 
RTP/RTCP ciphersuite values, as given in 
clause 6.3.3 of TS 101 909-4 [2]? 


6.3.3 [2] 


M 




NCS 32 


Does the E-MTA support RequestedEvents? 


6.3.4 [2] 


O 




NCS 33 


Does the E-MTA support Requestldentifier? 


6.3.4 [2] 


O 




NCS 34 


Does the E-MTA support DigitMap? 


6.3.4 [2] 







NCS 35 


Does the E-MTA support Signal Requests? 


6.3.4 [2] 







NCS_36 


Does the E-MTA support 
QuarantineHandling? 


6.3.4 [2] 







NCS 37 


Does the E-MTA support DetectEvents? 


6.3.4 [2] 







NCS_38 


Does the E-MTA support both a "graceful" or 
"forced" RestartlnProgress message? 


6.3.9 [2] 







Comments: 
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Table A.6: Failover and Race Conditions supported by the E-MTA 



Item 


Requirement 


Reference 


Status 


Support 


NCS_39 


Does the E-MTA support the Restart 
Procedure? 


6.4.3.5 [2] 


M 




NCS_40 


Are the steps defined in 6.4.3.6 of 

TS 101 909-4 [2] followed by an E-MTA 

where its endpoints become "disconnected"? 


6.4.3.6 [2] 


M 




NCS_41 


Does the E-MTA respect the requirement to 
send a RestartlnProgress command to the 
Call Agent at the beginning of the 
"disconnected" procedure? 


6.4.3.6 [2] 


M 




NCS_42 


Does the E-MTA provide silence on affected 
"disconnected" endpoints? 


6.4.3.6 [2] 


O 




NCS_43 


Does the E-MTA provide reorder tone to be 
played on affected "disconnected" endpoints? 


6.4.3.6 [2] 


O 




NCS_44 


Does the E-MTA enable a downloaded wav 
file to be played on affected "disconnected" 
endpoints? 


6.4.3.6 [2] 







Comments: 



Table A.7: Error Codes supported by the E-MTA 



Item 


Requirement 


Reference 


Status 


Support 


NCS_45 


Does the E-MTA support error code 517 - 
unsupported mode? 


6.3.3 [2] 


M 




NCS_46 


Does the E-MTA support error code 518 - 
unsupported package? 


6.1.6 [2] 


M 




NCS_47 


Does the E-MTA support error code 524 - 
LocalConnectionOptions inconsistency? 


6.3.3 [2] 


M 




NCS_48 


Does the E-MTA support error code 527 - 
missing RemoteConnectionDescriptor? 


6.3.3 [2] 


M 




NCS_49 


Does E-MTA adhere to the return codes as 
appropriate and specified in table 3, 
clause 6.5 of TS 101 909-4 [2] 


6.5 [2] 


M 




NCS_50 


Does the E-MTA support "error code 401 " for 
the ringing (rg) event as given in 
annex A of TS 101 909-4 [2]? 


Annex A [2] 


O 




NCS_51 


Does the E-MTA support "error code 401 " for 
the ringsplash (rs) event as given in 
annex A of TS 101 909-4 [2]? 


Annex A [2] 


O 




NCS_52 


Does the E-MTA support "error code 401 " for 
the distinctive ringing (rO, r1, r2, r3, r4, r5, r6 
or r7) event as given in annex A of 
TS101 909-4 [2]? 


Annex A [2] 


O 




NCS_53 


Does the E-MTA respect the requirement to 
return "error code 402" for the dial tone (dl) 
event as given in annex A of 
TS101 909-4 [2]? 


Annex A [2] 


M 




NCS_54 


Does the E-MTA respect the requirement to 
return "error code 402" for the stutter dial tone 
(si) event as given in annex A [2]? 


Annex A [2] 


M 




NCS_55 


Does the E-MTA respect the requirement to 
return "error code 402" for the DTMF tones 
(MFPB) event as given in annex A of 
TS 101 909-4 [2]? 


Annex A [2] 


M 




NCS_56 


Does the E-MTA respect the requirement to 
return "error code 402" for the busy tone (bz) 
event as given in annex A of 
TS 101 909-4 [2]? 


Annex A [2] 


M 
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Item 


Requirement 


Reference 


Status 


Support 


NCS_57 


Does the E-MTA respect the requirement to 
return "error code 402" for the congestion 
tone (cf) event as given in annex A of 
TS 101 909-4 [2]? 


Annex A [2] 


M 




NCS_58 


Does the E-MTA respect the requirement to 
return "error code 402" for the message 
waiting indicator (mwi) event as given in 
annex A of TS 101 909-4 [2]? 


Annex A [2] 


M 




NCS_59 


Does the E-MTA respect the requirement to 
return "error code 402" for the off-hook 
warning tone (ot) event as given in 
annex A of TS 101 909-4 [2]? 


Annex A [2] 


M 




NCS_60 


Does the E-MTA respect the requirement to 
return "error code 402" for the ring back tone 
(rt) event as given in annex A of 
TS101 909-4 [2]? 


Annex A [2] 


M 




NCS_61 


Does the E-MTA respect the requirement to 
return "error code 402" for the reorder tone 
(ro) event as given in annex A of 
TS 101 909-4 [2]? 


Annex A [2] 


M 




NCS_62 


Does the E-MTA respect the requirement to 
return "error code 402" for the call waiting 
tonel (wt1 , .., wt4) event as given in 
annex A of TS 101 909-4 [2]? 


Annex A [2] 


M 




Comments: 
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Table A.8: Event package (L) supported by the E-MTA 



Item 


Requirement 


Reference 


Status 


Support 


NCS_63 


When receiving Caller ID information, does 
the E-MTA support the following ASCII 
formatted data (ci(time, number, name))? 


Annex A [2] 


M 




NCS_64 


Does the E-MTA generate a fax tone (ft) 
event when an 

ITU-T Recommendation V.21 [26] fax 
preamble is detected? 


Annex A [2] 


M 




NCS_65 


Does the E-MTA generate a fax tone (ft) 
event when an 

ITU-T Recommendation T.30 [23] CNG tone 
is detected? 


Annex A [2] 


O 




NCS_66 


Does the E-MTA generate a media start (ma) 
event when the first valid RTP media packet 
is received on a connection? 


Annex A [2] 


M 




NCS_67 


Does the E-MTA generate a modem tone (mt) 
event whenever a data call is detected by 
presence of 

ITU-T Recommendation V.25 [27] answer 
tone (ANS) with or without phase reversal? 


Annex A [2] 


M 




NCS_68 


Does the E-MTA generate a modem tone (mt) 
event whenever a data call is detected by 
presence of ITU-T Recommendation V.8 [24] 
modified answer tone (ANSam) with or 
without phase reversal? 


Annex A [2] 


M 




NCS_69 


Does the E-MTA respect the requirement to 
generate an operation failure (of) event as 
described in annex A of TS 1 01 909-4 [2]? 


Annex A [2] 


O 




NCS_70 


Does the E-MTA support the generation of a 
TDD (Telecom Devices for the Deaf tones) 
event? 


Annex A [2] 


M 




NCS_71 


Does the E-MTA support the detection of a 

TDD call as per 

ITU-T recommendation V.18 [25]? 


Annex A [2] 


M 
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Table A.9: Event package (E) supported by the E-MTA 



Item 


Requirement 


Value 


Reference 


Status 


Support 


NCS_72 


Does the E-MTA allow the following cadence 
ringing values to be provisioned? 


>0 
< 127 


Annex B.4.1.1 
[2] 


M 




NCS_73 


Does the E-MTA support the default ring 
cadence values as specified in table B.1 , 
TS101 909-4 [2]? 




Annex B.4.1.1 
[2] 


M 




NCS_74 


If the pulse encoding duration (pd) is not 
provided by the requesting entity, does the 
E-MTA apply a provisioned or internally 
defaulted value, based on the line treatment 
(It) parameter (table B.3, TS 101 909-4 [2])? 




Annex 
B.4.2.4.1 [2] 


O 




NCS_75 


If the pulse period encoding duration (pr) is 
not provided by the requesting entity, does 
the E-MTA apply a provisioned or internally 
defaulted value, based on the line treatment 
(It) parameter (table B.3, TS 101 909-4 [2])? 




Annex 
B.4.2.4.1 [2] 


O 




NCS_76 


Does the E-MTA support meter pulse 
generation and application as defined in 
clause B.4.9 of TS 101 909-4 [2]? 




Annex 
B.4.9 [2] 


O 




NCS_77 


Does the E-MTA implement all the default line 
treatment values as specified in tables B.1 , 
B.2 and B.3 of TS 101 909-4 [2]? 




Annex 
B.5.1 [2] 


M 




NCS_78 


Does the E-MTA support the NCS Audit 
package as outlined in annex B.6.1 of 
TS101 909-4 [2]? 




Annex 
B.6.1 [2] 


M 




Comments: 



Table A.10: Event package (E) signals supported by the E-MTA 



Item 


Requirement 


Reference 


Status 


Support 


NCS_79 


Does the E-MTA support Cadence-Ringing 
signal (cr) as specified in annex B.4.1 ? 


Annex 
B.4.1 [2] 


M 




NCS_80 


Does the E-MTA support Pulsed Signal (ps) 
as specified in annex B.4.2? 


Annex 
B.4.2 [2] 


M 




NCS_81 


Does the E-MTA support Pulsed signal 
cancellation (pc) as specified in annex B.4.5? 


Annex 
B.4.5 [2] 


M 




NCS_82 


Does the E-MTA support Pulsed completion 
event (pc) as specified in annex B.4.6? 


Annex 
B.4.6 [2] 


M 




NCS_83 


Does the E-MTA support Pulsed signal failure 
event (of) as specified in annex B.4.7? 


Annex 
B.4.7 [2] 


M 




NCS_84 


Does the E-MTA support Steady-signal (ss) 
as specified in annex B.4.8? 


Annex 
B.4.8 [2] 


M 




NCS_85 


Does the E-MTA support Metering pulse 
generation (em) as specified in annex B.4.9? 


Annex 
B.4.9 [2] 


M 




Comments: 
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Table A.11 : NCS - DQoS interactions supported by the E-MTA 



Item 


Requirement 


Reference 


Status 


Support 


NCS_86 


Does the E-MTA use the classifiers as shown in table 
C.1 of TS 101 909-4 [2] for the resource reservation 
and commit? 


Annex C [2] 


M 




NCS_87 


Does the E-MTA use the classifiers as shown in table 
C.2 of TS 101 909-4 [2] for resource reservation and 
commit when the RemoteConnection Descriptor is not 
provided? 


Annex C [2] 


M 




Comments: 



Table A.12: Timer values supported by the E-MTA 



Item 


Requirement 


Value 


Reference 


Status 


Support 


NCS_88 


Is the default value for Td init equal to this 
value? 


15s 


6.4.3.6 [2] 


M 




NCS_89 


Is the default value for Td min equal to this 
value? 


15s 


6.4.3.6 [2] 


M 




NCS_90 


Is the default value for Td max equal to this 
value? 


600 s 


6.4.3.6 [2] 


M 




NCS_91 


In the case where Timer (t), as described in 
clause 6.15 [2], functions as an inter-digit 
timer for the "accumulate according to digit 
map" action; is the default value for partial 
dial timing (T ) equal to this value? 


16s 


Annex A [2] 


M 




NCS_92 


In the case where Timer (t), as described in 
clause 6.15 [2], functions as an inter-digit 
timer for the "accumulate according to digit 
map" action; is the default value for critical 
dial timing (T crit ) equal to this value? 


4s 


Annex A [2] 


M 




NCS 93 


Is Timer (t) provisionable? 


- 


Annex A [2] 


M 




NCS_94 


Is the default value of the Long duration 
connection (Id) period equal to this value? 


60 min 


Annex A [2] 


M 




NCS 95 


Is timer Id provisionable? 


- 


Annex A [2] 


M 




NCS 96 


Is the timeout (TO) signal provisionable? 


- 


Annex B.4.2 [2] 


M 




NCS 97 


What is the default TO value set at? 




Annex B.4.2 [2] 


Value= 




Comments: 



A.8 Dynamic Quality of Service (DQoS) 

Table A.13: Billing support by the E-MTA 



Item 


Requirement 


Reference 


Status 


Support 


DQoS_1 


Do all reservation requests that pass admission control fit within 
the authorization envelope? 


5.7.8 [3] 


M 




Comments: 
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Table A.14: RSVP extensions: header compression support by the E-MTA 



Item 


Requirement 


Reference 


Status 


Support 


DQoS_2 


Does the E-MTA support IP header 
compression or suppression? 


6.1.3 [3] 


M 




DQoS_3 


Does the E-MTA support IP checksum 
compression or suppression? 


6.1.3 [3] 


M 




DQoS_4 


Does the E-MTA support UDP checksum 
compression or suppression? 


6.1.3 [3] 


M 




DQoS_5 


Does the E-MTA respect the Tspec 
requirement to reflect a value corresponding 
to the data flow for which reservation is being 
requested? 


6.1.3 [3] 


M 




Comments: 



Table A.15: RSVP extensions: dynamic behaviour 



Item 


Requirement 


Reference 


Status 


Support 


DQoS_6 


Does the admission control fail, where there 
is a reservation that is no greater than the one 
currently installed? 


6.1.4 [3] 


M 




DQoS_7 


When using the resource-ID resource-id 
object, if the amount of resource requested in 
the new reservation is no greater than 
previously installed, does the admission 
control fail? 


6.1.4 [3] 


M 




Comments: 



Table A.16: RSVP extensions: authentication 



Item 


Requirement 


Reference 


Status 


Support 


DQoS_8 


Does the E-MTA include the RSVP-PATH 
messages in the Gate-ID policy data? 


6.1.6 [3] 


M 




Comments: 



Table A.17: RSVP flowspecs 



Item 


Requirement 


Reference 


Status 


Support 


DQoS_9 


The CODEC specification TS 101 909-3 [1] 
contains the mapping requirements of 
higher-layer service descriptions (e.g. SDP as 
used in VoIP applications) into Flowspecs. 
Does the E-MTA map Flowspecs as defined 
in ES 201 488 [9] layer 2 parameters? 


6.2 [3] 


M 




DQoS_1 


Where the rate R provided in the Rspec is the 
amount of bandwidth allocated to the flow. Is 
it greater than or equal to rfrom the Tspec for 
the this delay bound to hold? 


6.2 [3] 


M 




DQoSJ 1 


When a codec is changed in mid-session, can 
the E-MTA generate multiple Tspecs? 


6.2 [3] 


M 




Comments: 
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Table A.18: RSVP additional objects 



Item 


Requirement 


Reference 


Status 


Support 


DQoS_12 


Does the MTA support additional RSVP 
objects as in clause 6.3 of TS 101 909-5 [3]? 


6.3 [3] 


M 




Comments: 



Table A.19: RSVP definitions 



Item 


Requirement 


Reference 


Status 


Support 


DQoSJ 3 


Does the MTA support the enhanced RSVP 
messages? 


6.4 [3] 


M 




Comments: 



Table A.20: Reservation by the E-MTA 



Item 


Requirement 


Reference 


Status 


Support 


DQoS_14 


Can the MTA perform the Reservation 
Operation as outlined in clause 6.6 of 
TS101 909-5 [3]? 


6.5 [3] 


M 




Comments: 



Table A.21 : Support of commit message by the E-MTA 



Item 


Requirement 


Reference 


Status 


Support 


DQoS_1 5 


Does the MTA conform to the Commit 
messages as defined in clause 6.6 of 
TS101 909-5 [3]? 


6.6 [3] 


M 




DQoS_1 6 


After having sent the Commit message what 
timer is set? 


6.7 [3] 


Value= 




DQoS_1 7 


After having sent the Commit message what 
is the value of the timer? 


6.7 [3] 


Value= 




DQoS_1 8 


After having sent the Commit message how 
many reattempts are made if no 
acknowledgements are received? 


6.7 [3] 


Value= 




Comments: 
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A. 9 MTA device provisioning 



Table A.22: E-MTA addressing 



Item 


Requirement 


Reference 


Status 


Support 


Prov_1 


For the provisioning of an E-MTA device, are 
Both CM and MTA device provisioning steps 
performed? 


4.2 [4] 


M 




Prov_2 


Does the E-MTA have two IP addresses, 
(i.e. an IP address for the CM component, 
and a different IP address for the MTA 
component)? 


4.2 [4] 


M 




Prov_3 


Does the E-MTA have two MAC addresses, 
one MAC address for the CM component, and 
a different MAC address for the 
MTA-component? 


4.2 [4] 


M 




Comments: 



Table A.23: Support of Fully Qualified Domain Name (FQDN) by the E-MTA 



Item 


Requirement 


Reference 


Status 


Support 


Prov 4 


Is the FQDN included in the DHCP offer? 


4.2 [4] 


O 




Prov_5 


Is the FQDN included in the E-MTA 
configuration file when it is not included in the 
DHCP offer? 


4.2 [4] 


CM 




Prov_6 


In the condition as identified in Prov_4.2, is 
the mapping of the FQDN to IP address 
configured in the network DNS server? 


4.2 [4] 


CM 




Prov_7 


In the condition as identified in Prov_4.2, is 
the mapping of the FQDN to IP address 
available to the rest of the network? 


4.2 [4] 


CM 




Comments: 
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Table A.24: E-MTA configuration files 



Item 


Requirement 


Reference 


Status 


Support 


Prov_8 


Does E-MTA support a separate CM 
configuration file for the CM component as 
given in clause 4.2 of TS 101 909-6 [4]? 


4.2 [4] 


M 




Prov_9 


Does E-MTA support a separate MTA 
configuration file for the MTA component as 
given in clause 4.2 of TS 101 909-6 [4]? 


4.2 [4] 


M 




Prov_1 


Does the E-MTA support receipt of the 
configuration containing the parameters as given 
in clause 8.2 of TS 1 01 909-6 [4]? 


8.2 [4] 


M 




Prov_1 1 


Does the E-MTA discarded the MTA 
configuration file if it can not be authenticated 
as given in clause 8.2 of TS 101 909-6 [4]? 


8.2 [4] 


M 




Prov_12 


Does the E-MTA support the "Telephony 
Config File Start" attribute within the Device 
Level Configuration as given in table 9, 
clause 8.2.1 of TS 1 01 909-6 [4]? 


8.2.1 [4] 


M 




Prov_13 


Does the E-MTA support the "Telephony 
Config File End" attribute within the Device 
Level Configuration as given in table 9 of 
clause 8.2.1 of TS 1 01 909-6 [4]? 


8.2.1 [4] 


M 




Prov_14 


Does the E-MTA support the "Telephony MTA 
Admin State" attribute within the Device Level 
Configuration as given in table 9 of 
clause 8.2.1 of TS 1 01 909-6 [4]? 


8.2.1 [4] 


M 




Prov_15 


Does the E-MTA support the "IPCablecom 
MTA Device FQDN" attribute within the 
Device Level Configuration as given in table 9 
of clause 8.2.1 [4]? 


8.2.1 [4] 


M 




Prov_16 


Does the E-MTA support the "Telephony 
Service Provider SNMP Entity" attribute within 
the Device Level Configuration as given in 
table 9 of clause 8.2.1 of TS 101 909-6 [4]? 


8.2.1 [4] 


M 




Prov_17 


Does the E-MTA support the "Telephony 
Service Provider DHCP Server" attribute 
within the Device Level Configuration as 
given in table 9 of clause 8.2.1 of 
TS101 909-6 [4]? 


8.2.1 [4] 


M 




Prov_1 8 


Does the E-MTA support the "MTA Privacy 
Key" attribute within the Device Level 
Configuration as given in table 9 of 
clause 8.2.1 of TS 1 01 909-6 [4]? 


8.2.1 [4] 


M 




Prov_19 


Does the E-MTA support the "R0 cadence" 
attribute within the Device Level Service Data 
as given in table 10 of clause 8.2.1 of 
TS101 909-6 [4]? 


8.2.2 [4] 


M 




Prov_20 


Does the E-MTA support the "R6 cadence" 
attribute within the Device Level Service Data 
as given in table 10 of clause 8.2.1 of 
TS101 909-6 [4]? 


8.2.2 [4] 


M 




Prov_21 


Does the E-MTA support the "R7 cadence" 
attribute within the Device Level Service Data 
as given in table 10 of clause 8.2.1 of 
TS101 909-6 [4]? 


8.2.2 [4] 


M 
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Table A.25: Support of OSS server protocols by E-MTA 



Item 


Requirement 


Reference 


Status 


Support 


Prov_22 


Does the E-MTA support use of SNMPv3 
security for network management operations? 


4.2 [4] 


M 




Prov_23 


Does the E-MTA support Trivial File Transfer 
Protocol (TFTP)? 


4.2 [4] 


M 




Prov_24 


Does the E-MTA support BootP for 
communications with the Domain Name 
Server (DNS)? 


4.2 [4] 


M 




Prov 25 


Does the E-MTA support DHCP? 


4.2 [4] 


M 




Prov 26 


Does the E-MTA support HTTP? 


4.2 [4] 


M 




Prov_27 


Does the E-MTA support communication with 
the SYSLOG Server, as given in clause 4.2 of 
TS 101 909-6 [4]? 


4.2 [4] 


M 




Prov_28 


Does the E-MTA support RADIUS for 
communications with the Record Keeping 
Server (RKS)? 


4.2 [4] 


M 




Prov_29 


Does the E-MTA support Kerberos protocol 
with PKINIT extensions for communications 
with the Ticket Granting Server (TGS)? 


4.2 [4] 


M 




Comments: 



Table A.26: Support of DHCP by E-MTA 



Item 


Requirement 


Reference 


Status 


Support 


Prov_30 


Does the E-MTA support DHCP option 
code 60 (Vendor Client Identifiers defined in 
clause 7.2 of TS 101 909-6 [4]? 


4.4.4 [4] 


M 




Prov_31 


Does the E-MTA support DHCP option 
code 177 (IPCablecom Servers Option) as 
defined in clause 7.1 of TS 101 909-6 [4]? 


4.4.4 [4] 


M 




Prov_32 


Does the MTA DHCP client support broadcast 
messages? 


4.4.4 [4] 


M 




Prov_33 


Does the MTA DHCP client support unicast 
messages? 


4.4.4 [4] 


M 




Prov_34 


Does the E-MTA support the MTA's assigned 
FQDN in the DHCP offer message? 


4.4.4 [4] 


O 




Prov_35 


Does the MTA follow the DHCP 
(RFC 2131 [11]) specification timeout and 
retry mechanisms as given clause 6.1 of 
TS101 909-6 [4]? 


6.1 [4] 


M 




Prov_36 


Does the E-MTA encode the DHCP option 
code 60 in the CM-component of the DHCP 
discover message? 


7.2 [4] 


M 




Prov_37 


Does the E-MTA encode the DHCP option 
code 60 in the MTA-component of the DHCP 
discover message? 


7.2 [4] 


M 
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Table A.27: Support of TFTP by E-MTA 



Item 


Requirement 


Reference 


Status 


Support 


Prov_38 


Does the MTA support the TFTP access 
method for downloading the MTA 
configuration data file via an SNMPv3 SET 
from the provisioning server? 


4.4.8 [4] 


M 




Prov_39 


Does the MTA use an adaptive timeout for 
TFTP? 


6.1 [4] 


M 




Comments: 



Table A.28: Support of HTTP by E-MTA 



Item 


Requirement 


Reference 


Status 


Support 


Prov_40 


Does the MTA support HTTP access method 
for downloading the MTA configuration data 
file via an SNMPv3 SET from the provisioning 
server? 


4.4.8. [4] 


O 




Prov_41 


Does the MTA follow the HTTP specification 
timeout and retry mechanisms as given 
clause 6.1 of TS 101 909-6 [4]? 


6.1 [4] 


M 




Comments: 



Table A.29: Support of SNMP by E-MTA 



Item 


Requirement 


Reference 


Status 


Support 


Prov_42 


Does the E-MTA support the provisioning 
sequence of the SNMPv3 requirements as 
given in clause 4.4.1.2 of TS 101 909-6 [4]? 


4.4.1.2 [4] 


M 




Prov_43 


Does the E-MTA support SNMPv3 via the 
MTA MIB TS 101 909-8 [6] to modify services 
on an endpoint? 


6.3.1 [4] 


M 




Comments: 



Table A.30: Support of initialization sequences by E-MTA 



Item 


Requirement 


Reference 


Status 


Support 


Prov_44 


Does the E-MTA support the Power-On 
Initialization Flows as given in table 1 , 
clause 6.2 of TS 101 909-6 [4]? 


6.2 [4] 


M 




Prov_45 


Does the E-MTA support the initialization 
sequence described in clause 6 of 
TS101 909-6 [4]? 


6.5 [4] 


M 
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Table A.31 : Support of provisioning related security features by E-MTA 



Item 


Requirement 


Reference 


Status 


Support 


Prov_46 


Does the MTA generate a random number 
that will be exchanged as part of the device 
capability data to the Provisioning 
Application? 


4.4.1.1 [4] 


M 




Prov_47 


Is the nonce regenerated every time the MTA 
power-on initialization occurs? 


4.4.1.1 [4] 


M 




Prov_48 


Does the MTA generate a correlation number 
that will be exchanged as part of the device 
capability data to the Provisioning 
Application? 


4.4.1.1 [4] 


M 




Prov_49 


Does the MTA obtain an MTA Telephony 
Certificate (X.509 certificate) for each network 
operator's Call Management Server(s) (CMS) 
assigned to an MTA's voice communications 
endpoint? 


4.4.1.1 [4] 


M 




Prov_50 


Does the MTA obtain a Service Provider 
Certificate (X.509 certificate) from the network 
operator that "owns" the CMS assigned to an 
MTA's voice communications endpoint? 


4.4.1.1 [4] 


M 




Prov_51 


Does the MTA fail the provisioning operation 
under the conditions described in 
clause 4.4.1.1 ofTS101 909-6 [4] when both 
the MTA Telephony and Service Provider 
Certificates have not been provisioned? 


4.4.1.1 [4] 


M 




Prov_52 


Does the MTA fail the provisioning operation 
under the conditions described in 
clause 4.4.1 .1 of TS 1 01 909-6 [4] when a 
corresponding Local System Certificate is not 
provisioned for that endpoint? 


4.4.1.1 [4] 


M 




Prov_53 


Does the MTA obtain a single Kerberos ticket 
per TS 1 01 909-1 1 [8] under the conditions 
described in clause 4.4.1 .1 of 
TS101 909-6 [4]? 


4.4.1.1 [4] 


M 




Prov_54 


Does the E-MTA support non-duplication of 
Kerberos ticket requests as described in 
clause 4.4.1 .1 of TS 1 01 909-6 [4]? 


4.4.1.1 [4] 


M 




Prov_55 


Does the E-MTA initially establish a pair of 
IPSEC Security Associations (inbound and 
outbound) with one of the IP addresses 
returned by the DNS server as described in 
clause 4.4.1 .1 of TS 1 01 909-6 [4]? 


4.4.1.1 [4] 


M 




Prov_56 


Does the E-MTA also initially establish 
IPSEC Security Associations with the 
additional CMS IP addresses? 


4.4.1.1 [4] 


O 




Prov_57 


Does the E-MTA not attempt to establish 
additional Security Associations with the 
same CMS IP address as described in 
clause 4.4.1 .1 of TS 1 01 909-6 [4]? 


4.4.1.1 [4] 


M 




Prov_58 


Does the MTA verify the authenticity of the 
configuration file it downloads from the 
server? 


5.1 [4] 


M 




Prov_59 


Does the MTA implement the backoff 
specifications, defined in the security 
specification (TS 101 909-1 1 [8]) for the 
security message flows? 


6.1. [4] 


M 




Prov_60 


Does the MTA implement the retry 
specifications, defined in the security 
specification (TS 101 909-1 1 [8]) for the 
security message flows? 


6.1. [4] 


M 
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A.10 Management Information Base (MIB) 
A. 10.1 Management Information Base framework 

Table A.32: MIB framework 



Item 


Requirement 


Reference 


Status 


Support 


MIB_1 


Does the E-MTA comply with ITU-T 
Recommendation J. 83 [21]? 


5.2 [5] 


M 




MIB_2 


Does the E-MTA comply with ITU-T 
Recommendation J.112 [22]? 


5.2 [5] 


M 




MIB_3 


Do the MIBs implemented by the E-MTA 
comply with SMIv2 as defined in IETF 
RFC 2578 [15]? 


5.2 [5] 
5.2.3 [5] 


M 




MIB_4 


Do the MIBs implemented by the E-MTA 
comply with SNMPv2 as defined in IETF 
RFC 2579 [16]? 


5.2 [5] 
5.2.3 [5] 


M 




MIB_5 


Are the IPCablecom MIBs implemented to be 
independent of the Cable Modem? 


5.2.2 [5] 


M 




MIB_6 


Does the E-MTA provide MIB definitions for 
attributes that are required in the MTA device 
provisioning flows? 


5.3.1 [5] 


O 




MIB_7 


Does the MIB implemented by the E-MTA 
provide attributes for the support of Quality of 
Service (QoS)? 


5.3.3 [5] 


O 




MIB_8 


Are the MIB implemented by the E-MTA 
interoperable with the QoS definitions of 
ITU-T Recommendation J.112 [22]? 


5.3.3 [5] 


O 




MIB_9 


Does the MIB implemented by the E-MTA 
provide the attributes that are needed to 
satisfy the high availability requirements of 
the voice communications service? 


5.3.4 [5] 


O 




MIBJ0 


Does the MIB implemented by the E-MTA 
provide the attributes that can be used to 
manage voice ports on the MTA? 


5.3.5 [5] 


O 




MIBJ1 


Does the MIB implemented by the E-MTA 
provide the attributes that are needed for 
management of the NCS packet voice call 
signalling protocol? 


5.3.6 [5] 


O 




MIBJ2 


Does the MIB implemented by the E-MTA 
provide the attributes that can be used to 
monitor and manage packet voice transport? 


5.3.7 [5] 


O 




MIBJ3 


Is the Real Time Protocol (RTP) MIB 
(RFC 2959 [29]) implemented? 


5.3.7 [5] 


O 




MIB_14 


Does the MIB implemented by the E-MTA 
provide the attributes that can be used in 
monitoring of the performance of the network 
when used for voice communications? 


5.3.8 [5] 


O 




MIBJ5 


Does the MIB implemented by the E-MTA 
provide Packet counts? 


5.3.8 [5] 


O 




MIBJ6 


Does the MIB implemented by the E-MTA 
provide Call signalling status? 


5.3.8 [5] 


O 




NOTE: The ETSI source document will eventually be replaced by an IETF RFC, further 
checking will be required once this task has been completed. 
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A. 10.2 MTA Management Information Base (MIB) 



Table A.33: MTA MIB 



Item 


Requirement 


Reference 


Status 


Support 


MTA_MIB_1 


Does the E-MTA respect the requirement to 
obtain a new Kerberos ticket (with a PKINIT 
exchange) s 15 min before the old ticket 
expires? 


4 [6] 


M 




MTA_MIB_2 


When E-MTA Telephony certificate is signed 
by a Local System CA, what is value of the 
ASN.1 DER encoding parameter? 


4 [6] 


Value= 




MTA_MIB_3 


When E-MTA Telephony certificate is signed 
by a Local System CA, is it a non-empty 
value? 


4 [6] 


M 




MTA_MIB_4 


When E-MTA Telephony certificate is signed 
by a Local System CA, does it have a length 
of 0? 


4 [6] 


M 




MTA_MIB_5 


Does the E-MTA generate events between 
warning and emergency at appropriate levels 
of problems? 


4 [6] 


O 




MTA_MIB_6 


During the occurrence of the 
pktcMtaDevEvReporting event class, does the 
E-MTA allow traps to be disabled? 


4 [6] 


M 




MTA_MIB_7 


During the occurrence of the 
pktcMtaDevEvReporting event class, does the 
E-MTA allow syslogging to be disabled? 


4 [6] 


M 




MTA_MIB_8 


During the occurrence of the 
pktcMtaDevEvReporting event class, does the 
E-MTA implement internal logging when the 
local(O) bit is set? 


4 [6] 


M 




MTA_MIB_9 


During the occurrence of the 
pktcMtaDevEvReporting event class, does the 
E-MTA generate a trap when the traps(1 ) bit 
is set? 


4 [6] 


M 




MTA_MIB_10 


During the occurrence of the 
pktcMtaDevEvReporting event class, assuming 
the syslog address is set, does the E-MTA 
send a syslog message when the syslog(2) 
bit is set? 


4 [6] 


M 




MTA_MIB_11 


When reporting multiple events via the same 
entry, does the E-MTA provide the time that 
the last event for this entry occurred? 


4 [6] 


O 




MTA_MIB_12 


Does the E-MTA report the same value as 
pktcMtaDevEvFi rstTi me? 


4 [6] 


O 




NOTE: The ETSI source document will eventually be replaced by an IETF RFC, further checking will 
be required once this task has been completed. 
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A. 10.3 Management Information Base signalling 



Table A.34: Signalling MIB 



Item 


Requirement 


Reference 


Status 


Support 


SIG_MIB_1 


Does the E-MTA implement the syntax for the 
signalling MIB as specified in clause 4 of 
TS101 909-9 [7]? 


4 [7] 


M 




SIG_MIB_2 


Does the E-MTA support the syntax for the 
PktcCodecType other(1), as specified in 
clause 4 of TS 101 909-9 [7]? 


4 [7] 


O 




SIG_MIB_3 


Does the E-MTA support the syntax for the 
PktcCodecType unknown(2), as specified in 
clause 4 of TS 101 909-9 [7]? 


4 [7] 


O 




SIG_MIB_4 


Does the E-MTA support the syntax for the 
PktcCodecType g729(3), as specified in 
clause 4 of TS 101 909-9 [7]? 


4 [7] 


O 




SIG_MIB_5 


Does the E-MTA support the syntax for the 
PktcCodecType g729a(4), as specified in 
clause 4 of TS 101 909-9 [7]? 


4 [7] 


O 




SIG_MIB_6 


Does the E-MTA support the syntax for the 
PktcCodecType g729e(5), as specified in 
clause 4 of TS 101 909-9 [7]? 


4 [7] 


O 




SIG_MIB_7 


Does the E-MTA support the syntax for the 
PktcCodecType g71 1mu(6), as specified in 
clause 4 of TS 101 909-9 [7]? 


4 [7] 


O 




SIG_MIB_8 


Does the E-MTA support the syntax for the 
PktcCodecType g726(7), as specified in 
clause 4 of TS 101 909-9 [7]? 


4 [7] 


O 




SIG_MIB_9 


Does the E-MTA support the syntax for the 
PktcCodecType g728(8), as specified in 
clause 4 of TS 101 909-9 [7]? 


4 [7] 


O 




SIG_MIB_10 


Does the E-MTA support the syntax for the 
PktcCodecType g71 1a(9), as specified in 
clause 4 of TS 101 909-9 [7]? 


4 [7] 


M 




SIG_MIB_11 


Does the E-MTA support the syntax for 
PktcRingCadence, as specified in clause 4 of 
TS101 909-9 [7]? 


4 [7] 


M 




SIG_MIB_12 


Does the E-MTA support the syntax for 
PktcSigType, as specified in clause 4 of 
TS101 909-9 [7]? 


4 [7] 


M 




SIG_MIB_13 


Does the E-MTA implement the object 
identifier for pktcSigMibObjects, as specified 
in clause 4 of TS 101 909-9 [7]? 


4 [7] 


M 




SIG_MIB_14 


Does the E-MTA implement the object 
identifier for pktcSigDevConfigObjects, as 
specified in clause 4 of TS 101 909-9 [7]? 


4 [7] 


M 




SIG_MIB_15 


Does the E-MTA implement the object 
identifier for pktcNcsEndPntConfigObjects, as 
specified in clause 4 of TS 101 909-9 [7]? 


4 [7] 


M 




SIG_MIB_16 


Does the E-MTA implement the object 
identifier for pktcSigEndPntConfigObjects, as 
specified in clause 4 of TS 101 909-9 [7]? 


4 [7] 


M 




SIG_MIB_17 


Does the E-MTA implement the object 
identifier for pktcDcsEndPntConfigObjects, as 
specified in clause 4 of TS 101 909-9 [7]? 


4 [7] 


M 




SIG_MIB_18 


Does the E-MTA implement the object type 
pktcSigDevCodecTable, as specified in 
clause 4 of TS 101 909-9 [7]? 


4 [7] 


M 




SIG_MIB_19 


Does the E-MTA implement the object type 
pktcSigDevCodecEntry, as specified in 
clause 4 of TS 101 909-9 [7]? 


4 [7] 


M 




SIG_MIB_20 


Does the E-MTA implement the object type 
pktcSigEndPntConfigTable, as specified in 
clause 4 of TS 101 909-9 [7]? 


4 [7] 


M 
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Item 


Requirement 


Reference 


Status 


Support 


SIG_MIB_21 


Does the E-MTA implement the object type 
pktcSigDevCodeclndex, as specified in 
clause 4 of TS 101 909-9 [7]? 


4 [7] 


M 




SIG_MIB_22 


Does the E-MTA implement the object type 
pktcSigDevEchoCancellation, as specified in 
clause 4 of TS 101 909-9 [7]? 


4 [7] 


M 




SIG_MIB_23 


Does the E-MTA implement the object type 
pktcSigDevSilenceSuppression, as specified 
in clause 4 of TS 101 909-9 [7]? 


4 [7] 


M 




SIG_MIB_24 


Does the E-MTA implement the object type 
pktcSigDevConnectionMode, as specified in 
clause 4 of TS 101 909-9 [7]? 


4 [7] 


M 




SIG_MIB_25 


Does the E-MTA implement the object type 
pktcSigDevROCadence, as specified in 
clause 4 of TS 101 909-9 [7]? 


4 [7] 


M 




SIG_MIB_26 


Does the E-MTA implement the object type 
pktcSigDevR6Cadence, as specified in 
clause 4 of TS 101 909-9 [7]? 


4 [7] 


M 




SIG_MIB_27 


Does the E-MTA implement the object type 
pktcSigDevR7Cadence, as specified in 
clause 4 of TS 101 909-9 [7]? 


4 [7] 


M 




SIG_MIB_28 


Does the E-MTA implement the object type 
pktcSigDefCallSigTos, as specified in 
clause 4 of TS 101 909-9 [7]? 


4 [7] 


M 




SIG_MIB_29 


Does the E-MTA implement the object type 
pktcSigDefMediaStreamTos, as specified in 
clause 4 of TS 101 909-9 [7]? 


4 [7] 


M 




SIG_MIB_30 


Does the E-MTA implement the object type 
pktcSigTosFormatSelector, as specified in 
clause 4 of TS 101 909-9 [7]? 


4 [7] 


M 




SIG_MIB_31 


Does the E-MTA implement the object type 
pktcSigCapabilityTable, as specified in 
clause 4 of TS 101 909-9 [7]? 


4 [7] 


M 




SIG_MIB_32 


Does the E-MTA implement the object type 
pktcSigCapabilityEntry, as specified in 
clause 4 of TS 101 909-9 [7]? 


4 [7] 


M 




SIG_MIB_33 


Does the E-MTA implement the object type 
pktcSignalinglndex, as specified in clause 4 of 
TS 101 909-9 [7]? 


4 [7] 


M 




SIG_MIB_34 


Does the E-MTA implement the object type 
pktcSignalingType, as specified in clause 4 of 
TS101 909-9 [7]? 


4 [7] 


M 




SIG_MIB_35 


Does the E-MTA implement the object type 
pktcSignalingVersion, as specified in 
clause 4 of TS 101 909-9 [7]? 


4 [7] 


M 




SIG_MIB_36 


Does the E-MTA implement the object type 
pktcSignalingVendorExtension, as specified 
in clause 4 of TS 101 909-9 [7]? 


4 [7] 


M 




SIG_MIB_37 


Does the E-MTA implement the object type 
pktcSigEndPntConfigTable, as specified in 
clause 4 of TS 101 909-9 [7]? 


4 [7] 


M 




SIG_MIB_38 


Does the E-MTA implement the object type 
pktcSigEndPntConfigEntry, as specified in 
clause 4 of TS 101 909-9 [7]? 


4 [7] 


M 




SIG_MIB_39 


Does the E-MTA implement the object type 
pktcSigEndPntCapabilitylndex, as specified in 
clause 4 of TS 101 909-9 [7]? 


4 [7] 


M 




SIG_MIB_40 


Does the E-MTA implement the object type 
pktcNcsEndPntConfigTable, as specified in 
clause 4 of TS 101 909-9 [7]? 


4 [7] 


M 




SIG_MIB_41 


Does the E-MTA implement the object type 
pktcNcsEndPntConfigEntry, as specified in 
clause 4 of TS 101 909-9 [7]? 


4 [7] 


M 
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Item 


Requirement 


Reference 


Status 


Support 


SIG_MIB_42 


Does the E-MTA implement the object type 
pktcNcsEndPntConfigCallAgentld, as 
specified in clause 4 of TS 101 909-9 [7]? 


4 [7] 


M 




SIG_MIB_43 


Does the E-MTA implement the object type 
pktcNcsEndPntConfigCallAgentUdpPort, as 
specified in clause 4 of TS 101 909-9 [7]? 


4 [7] 


M 




SIG_MIB_44 


Does the E-MTA implement the object type 
pktcNcsEndPntConfigPartialDialTO, as 
specified in clause 4 of TS 101 909-9 [7]? 


4 [7] 


M 




SIG_MIB_45 


Does the E-MTA implement the object type 
pktcNcsEndPntConfigCriticalDialTO, as 
specified in clause 4 of TS 101 909-9 [7]? 


4 [7] 


M 




SIG_MIB_46 


Does the E-MTA implement the object type 
pktcNcsEndPntConfigBusyToneTO, as 
specified in clause 4 of TS 101 909-9 [7]? 


4 [7] 


M 




SIG_MIB_47 


Does the E-MTA implement the object type 
pktcNcsEndPntConfigDialTone TO, as 
specified in clause 4 of TS 101 909-9 [7]? 


4 [7] 


M 




SIG_MIB_48 


Does the E-MTA implement the object type 
pktcNcsEndPntConfigMessage Waiting TO, as 
specified in clause 4 of TS 101 909-9 [7]? 


4 [7] 


M 




SIG_MIB_49 


Does the E-MTA implement the object type 
pktcNcsEndPntConfigOffHookWarnToneTO, 
as specified in clause 4 of TS 101 909-9 [7]? 


4 [7] 


M 




SIG_MIB_50 


Does the E-MTA implement the object type 
pktcNcsEndPntConfigFtingingTO, as specified 
in clause 4 of TS 101 909-9 [7]? 


4 [7] 


M 




SIG_MIB_51 


Does the E-MTA implement the object type 
pktcNcsEndPntConfigFtingBackTO, as 
specified in clause 4 of TS 101 909-9 [7]? 


4 [7] 


M 




SIG_MIB_52 


Does the E-MTA implement the object type 
pktcNcsEndPntConfigReorderTone TO, as 
specified in clause 4 of TS 101 909-9 [7]? 


4 [7] 


M 




SIG_MIB_53 


Does the E-MTA implement the object type 
pktcNcsEndPntConfigStutterDialTone TO, as 
specified in clause 4 of TS 101 909-9 [7]? 


4 [7] 


M 




SIG_MIB_54 


Does the E-MTA implement the object type 
pktcNcsEndPntConfigTSMax, as specified in 
clause 4 of TS 101 909-9 [7]? 


4 [7] 


M 




SIG_MIB_55 


Does the E-MTA implement the object type 
pktcNcsEndPntConfigMaxI , as specified in 
clause 4 of TS 101 909-9 [7]? 


4 [7] 


M 




SIG_MIB_56 


Does the E-MTA implement the object type 
pktcNcsEndPntConfigMax2, as specified in 
clause 4 of TS 101 909-9 [7]? 


4 [7] 


M 




SIG_MIB_57 


Does the E-MTA implement the object type 
pktcNcsEndPntConfigMax 1 QEnable, as 
specified in clause 4 of TS 101 909-9 [7]? 


4 [7] 


M 




SIG_MIB_58 


Does the E-MTA implement the object type 
pktcNcsEndPntConfigMax2QEnable, as 
specified in clause 4 of TS 101 909-9 [7]? 


4 [7] 


M 




SIG_MIB_59 


Does the E-MTA implement the object type 
pktcNcsEndPntConfigMWD, as specified in 
clause 4 of TS 101 909-9 [7]? 


4 [7] 


M 




SIG_MIB_60 


Does the E-MTA implement the object type 
pktcNcsEndPntConfigTdinit, as specified in 
clause 4 of TS 101 909-9 [7]? 


4 [7] 


M 




SIG_MIB_61 


Does the E-MTA implement the object type 
pktcNcsEndPntConfigTdmin, as specified in 
clause 4 of TS 101 909-9 [7]? 


4 [7] 


M 




SIG_MIB_62 


Does the E-MTA implement the object type 
pktcNcsEndPntConfigTdmax, as specified in 
clause 4 of TS 101 909-9 [7]? 


4 [7] 


M 
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Item 


Requirement 


Reference 


Status 


Support 


SIG_MIB_63 


Does the E-MTA implement the object type 
pktcNcsEndPntConfigRtoMax, as specified in 
clause 4 of TS 101 909-9 [7]? 


4 [7] 


M 




SIG_MIB_64 


Does the E-MTA implement the object type 
pktcNcsEndPntConfigRtolnit, as specified in 
clause 4 [7]? 


4 [7] 


M 




SIG_MIB_65 


Does the E-MTA implement the object type 
pktcNcsEndPntConfigLongDurationKeepAlive 
as specified in clause 4 of TS 101 909-9 [7]? 


4 [7] 


M 




SIG_MIB_66 


Does the E-MTA implement the object type 
pktcNcsEndPntConfigThist, as specified in 
clause 4 of TS 101 909-9 [7]? 


4 [7] 


M 




SIG_MIB_67 


Does the E-MTA implement the object type 
pktcNcsEndPntConfigStatus, as specified in 
clause 4 of TS 101 909-9 [7]? 


4 [7] 


M 




SIG_MIB_68 


Does the E-MTA implement the object 
identifier for pktcSigNotification, as specified 
in clause 4 of TS 101 909-9 [7]? 


4 [7] 


M 




SIG_MIB_69 


Does the E-MTA implement the object 
identifier for pktcSigConformance, as 
specified in clause 4 of TS 101 909-9 [7]? 


4 [7] 


M 




SIG_MIB_70 


Does the E-MTA implement the object 
identifier for pktcSigCompliances, as specified 
in clause 4 of TS 101 909-9 [7]? 


4 [7] 


M 




SIG_MIB_71 


Does the E-MTA implement the object 
identifier for pktcSigGroups, as specified in 
clause 4 of TS 101 909-9 [7]? 


4 [7] 


M 




NOTE: The ETSI source document will eventually be replaced by an IETF RFC, further checking will 
be required once this task has been completed. 


Comments: 



A.1 1 Security mechanisms 



Table A.35: Protection against theft of service 

NOTE: This table has been deleted as a solution needs to be included in the base specification that states specific 
requirements. 

Table A.36: Support of security interfaces by the E-MTA 



Item 


Requirement 


Reference 


Status 


Support 


SEC 1 


Does the E-MTA support pkt-sO? 


5.3.1 


table 1 [8] 


M 




SEC 2 


Does the E-MTA support pkt-s1 ? 


5.3.1 


table 1 [8] 


M 




SEC 3 


Does the E-MTA support pkt-s2? 


5.3.1 


table 1 [8] 


M 




SEC 4 


Does the E-MTA support pkt-s3? 


5.3.1 


table 1 [8] 


M 




SEC 5 


Does the E-MTA support pkt-s4? 


5.3.1 


table 1 [8] 


M 




SEC 6 


Does the E-MTA support pkt-s5? 


5.3.1 


table 1 [8] 


M 




SEC 7 


Does the E-MTA support pkt-s12? 


5.3.1 


table 1 [8] 


M 




SEC 8 


Does the E-MTA support pkt-s13? 


5.3.1 


table 1 [8] 


M 




Comments: 



ETSI 



36 



ETSI TS 101 909-26-1 V1.1.1 (2003-06) 



Table A.37: Security mechanisms supported by the E-MTA 



Item 


Requirement 


Reference 


Status 


Support 


SEC 9 


Does the E-MTA support Kerberos? 


6.4.2 [8] 


M 




SEC 10 


Does the E-MTA support SMNP v3? 


6.3 [8] 


M 




SEC 11 


Does the E-MTA support PKINIT? 


6.4.3 [8] 


M 




SEC 12 


Does the E-MTA support IPSec? 


6.1 [8] 


M 




Comments: 



Table A.38: Root private key compromise protection 



Item 


Requirement 


Reference 


Status 


Support 


SEC 13 


What is the length of the root private key? 


5.3.2.3 [8] 


Value= 




Comments: 



Table A.39: Authentication and encryption mechanisms 



Item 


Requirement 


Reference 


Status 


Support 


SECJ4 


Does the E-MTA support IPSec as given in 
IETF RFC 2406 [12]? 


6.1.2.1 [8] 


M 




SEC J 5 


Does the E-MTA support IPSec Transform ID 
ESP 3DES? 


6.1.2.1 [8] 


M 




SECJ6 


Does the E-MTA support IPSec Transform ID 
ESP NULL? 


6.1.2.1 [8] 


M 




SECJ7 


Does the E-MTA support IPSec Transform ID 
ESP AES? 


6.1.2.1 [8] 


O 




SECJ8 


On each of the MTA interfaces that requires 
confidentiality, is the ESP_NULL transform ID 
used? 


6.1.2.1 [8] 


M 




SECJ9 


Does the E-MTA support HMAC-MD5 
authentication algorithm? 


6.1.2.2 [8] 


M 




SEC_20 


Does the E-MTA support HMAC-SHA 
authentication algorithm? 


6.1.2.2 [8] 


M 




SEC_21 


Does the E-MTA support the 
SNMPv3_HMAC-MD5 Authentication 
Algorithm? 


6.3.2 [8] 


M 
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Table A.40: E-MTA profile for IPSec ESP (transport mode) 



Item 


Requirement 


Reference 


Status 


Support 


SEC_22 


Does the E-MTA support the IPSec 
anti-replay service as defined in 
IETF RFC 2406 [12]? 


6.1.2.3 [8] 


M 




SEC_23 


Is the IPSec anti-replay service turned on at 
all times? 


6.1.2.3 [8] 


M 




SEC_24 


Does the E-MTA automatically create IPsec 
Security Associations? 


6.1.2.4 [8] 


M 




SEC_25 


Does the E-MTA automatically update IPsec 
Security Associations? 


6.1.2.4 [8] 


M 




SEC_26 


Does the E-MTA automatically delete IPsec 
Security Associations? 


6.1.2.4 [8] 


M 




SEC_27 


Does the E-MTA automatically re-establish 
IPsec Security Associations as given in 
clause 6.1 .2.4 of TS 1 01 909-1 1 [8]? 


6.1.2.4 [8] 


M 




Comments: 



Table A.41 : Support of key management procedures by the E-MTA 



Item 


Requirement 


Reference 


Status 


Support 


SEC_28 


Does the E-MTA support Kerberos/PKINIT on 
the MTA-CMS signalling interface? 


6.1.2.4 [8] 


M 




SEC_29 


Does the E-MTA specify UDP port number 
1293 for all key management messages 
between the client and the Application 
Server? 


6.5.2 [8] 


M 




SEC_30 


Does the E-MTA perform a configurable 
backoff and resend procedure for any KDC 
requests that have not been acknowledged by 
the server? 


6.4.9 [8] 


M 




SEC_31 


Does the E-MTA perform a configurable 
backoff and resend procedure for any 
application server requests that have not 
been acknowledged by the server? 


6.4.9 [8] 


M 




SEC_32 


Does the E-MTA support the configuration 
backoff and resend procedure and any 
subsequent fault consistent with the 
procedure described in TS 101 909-4 [2]? 


6.4.9 [8] 


M 




SEC_33 


Does the E-MTA ensure that the key 
Management for the MTA-Provisioning 
SNMPv3 user uses the Kerberized key 
management protocol as given in 
clause 6.5.7 of TS 1 01 909-1 1 [8]? 


7.1.1.3.1 [8] 


M 




SEC_34 


Is the E-MTA manufactured with a public RSA 
key pair? 


7.1.1.4 [8] 


M 




SEC_35 


Is the E-MTA manufactured with a private 
RSA key pair? 


7.1.1.4 [8] 


M 




SEC_36 


Is the E-MTA manufactured with a X.509 
device certificate? 


7.1.1.4 [8] 


M 




SEC_37 


Is the E-MTA X.509 device certificate different 
from the BPI+ device certificate? 


7.1.1.4 [8] 


M 




SEC_38 


Does the MTA use Kerberos with PKINIT to 
obtain a CMS service ticket as described in 
clause 6.4.4 [8]? 


7.4.1.4.1 [8] 


M 




SEC_39 


Does the E-MTA execute a Kerberized key 
management protocol after the MTA has 
obtained a CMS ticket? 


7.4.1.4.1 [8] 


M 
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Table A.42: Support of Kerberos / PKINIT by the E-MTA 



Item 


Requirement 


Reference 


Status 


Support 


SEC_40 


Once the E-MTA client support the process of 
Ticket Granting Ticket (TGT) from the KDC , 
as specified in 6.4.2 of TS 1 01 909-1 1 [8]. 


6.4.2 [8] 


CM 1 




SEC_41 


Does the E-MTA implementation use the 
Kerberised symmetric session key to 
establish a pair of keys for the IPSec ESP 
protocol? 


6.4.2 [8] 


M 




SEC_42 


Does the E-MTA implementation utilize the 
PKINIT exchange to obtain Application Server 
tickets directly? 


6.4.3.1 [8] 


CM 1 




SEC_43 


Does the E-MTA obtain Application Server 
tickets, using the TGT process as specified in 
6.4.3.1 ofTS101 909-11 [8]? 


6.4.3.1 [8] 


CM 1 




SEC_44 


Does the E-MTA initiate the PKINIT exchange 
as given in clause 6.4.3.1 of 
TS101 909-11 [8]? 


6.4.3.1 [8] 


CM 2 




SEC_45 


Does the E-MTA use IP fragmentation to 
send large UDP packets? 


6.4.3.1 [8] 


M 




SEC_46 


Does the E-MTA clock drift less than 2.5 
minutes within a 7 days period? 


6.4.3.1 [8] 


M 




SEC_47 


Is the PKINIT Grace Period (PKINITqp) at 
least 15 min? 


6.4.3.1 [8] 


CM 2 




SEC_48 


Does the E-MTA client use the PKINITqp 
value to refresh the TGT? 


6.4.6.4 [8] 


M 




SEC_49 


Does the client support Ephemeral- 
Ephemeral Diffie-Hellman exchange? 


6.4.3.1.1 [8] 


M 




SEC_50 


Does the client implementation of the 
Diffie-Hellman parameters follow the IKE 
specification in IETF RFC 2409 [13]? 


6.4.3.1.1 [8] 


M 




SEC_51 


Does the client not support Static-Ephemeral 
Diffie-Hellman exchange? 


6.4.3.1.1 [8] 


M 




SEC_52 


Does the E-MTA support the Kerberos AS 
request / AS reply messages as specified in 
clause 6.4.3.2 of TS 1 01 909-1 1 [8]? 


6.4.3.2 [8] 


M 




SEC_53 


Does the E-MTA support the Kerberos AS 
request / AS reply exchange as specified in 
clause 6.4.4 of TS 1 01 909-1 1 [8]? 


6.4.4 [8] 


M 




SEC_54 


Does the E-MTA support the Kerberos TGS 
Request/TGS Reply Exchange as specified in 
clause 6.4.5 of TS 1 01 909-1 1 [8]? 


6.4.5 [8] 


M 




SEC_55 


Does the E-MTA client initiate the TGS 
Request/Reply exchange as specified in 
clause 6.4.5 of TS 1 01 909-1 1 [8]? 


6.4.5 [8] 


M 




SEC_56 


Does the E-MTA client implement the TGS 
Request as specified in clause 6.4.5.1 of 
TS101 909-11 [8]? 


6.4.5.1 [8] 


M 




SEC_57 


Does the E-MTA support the Kerberos AP 
request / AP reply messages as specified in 
clause 6.5.3 of TS 1 01 909-1 1 [8]? 


6.5.3 [8] 


M 




SEC_58 


Does the E-MTA support the Kerberos AP 
request / AP reply exchange as specified in 
clause 6.5.3 of TS 1 01 909-1 1 [8]? 


6.5.3 [8] 


M 




CM 1 : At least one method must be implemented by the E-MTA. An E-MTA may optionally 

support both methods. 
CM 2 : On interfaces where PKINIT GP is not defined, the MTA SHOULD perform PKINIT 

exchanges on-demand. 
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Table A.43: PKINIT request support by the E-MTA 



Item 


Requirement 


Reference 


Status 


Support 


SEC_59 


Does the E-MTA implement only the fields 

specified in clause 6.4.3.1 .1 of 

TS 1 01 909-1 1 [8] for the PKINIT request 

[PA-PK-AS-REQ]? 


6.4.3.1.1 [8] 


M 




SEC_60 


Does the pachecksum field use the Kerberos 
checksum type rsa-md5? 


6.4.3.1.1 [8] 


M 




SEC_61 


Does the E-MTA client ensure that the 
PA-PK-AS-REQ Certificate field contains an 
MTA Device Certificate? 


6.4.3.1.1 [8] 


M 




SEC_62 


Does the E-MTA client ensure that the 
PA-PK-AS-REQ Certificate field contains an 
MTA Manufacturer Certificate? 


6.4.3.1.1 [8] 


M 




SEC_63 


Does the E-MTA client ensure that the 
PA-PK-AS-REQ Certificate field does not 
contain Certificates other than those for the 
MTA Device and MTA Manufacturer? 


6.4.3.1.1 [8] 


M 




Comments: 



Table A.44: PKINIT reply support by the E-MTA 



Item 


Requirement 


Reference 


Status 


Support 


SEC_64 


Does the E-MTA implement the fields exactly 
as specified in clause 6.4.3.1 .2 of 
TS 1 01 909-1 1 [8] for the PKINIT reply 
[PA-PK-AS-REP]? 


6.4.3.1.2 [8] 


M 




SEC_65 


Does the client implementation of the PKINIT 
reply message (PA-PK-AS-REP) only use the 
dhSignedData choice? 


6.4.3.1.2 [8] 


M 




SEC_66 


Does the client implementation of the 
dhSignedData choice parameter 
"digestAlgorithms" contain an algorithm 
identifier for SHA-1? 


6.4.3.1.2 [8] 


M 




SEC_67 


Does the client verify that the AS Reply 
Kerberos etype value is des3-cbc-md5? 


6.4.3.1.2 [8] 


M 




SEC_68 


Does the client use PA-PK-AS-REP to 
determine the encryption key used on the AS 
Reply? 


6.4.3.1.2 [8] 


M 




SEC_69 


Does the client check the value of the nonce 
in the eContentfield? 


6.4.3.1.2 [8] 


M 




SEC_70 


Does the client check the validity of the KDC 
certificate? 


6.4.3.1.2 [8] 


M 




SEC_71 


Does the client check the validity of the 
signature in the Signerlnfo field? 


6.4.3.1.2 [8] 


M 




SEC_72 


Does the client fully support the timing related 
Kerberos error code [KRB-ERROR] as 
specified in clause 6.4.3.1.2.1 of 
TS101 909-11 [8]? 


6.4.3.1.2.1.1 [8] 


M 




SEC_73 


In the case that a KDC request fails due to a 
clock skew error [KRB_AP_ERR_SKEW], 
does the client immediately retry after 
adjusting the Kerberos timestamp inside the 
KDC Request message? 


6.4.3.1.2.1.1 [8] 


M 




SEC_74 


Does the MTA validate the time offset 
returned in the clock skew error message to 
ensure that it does not exceed the maximum 
of 1 hour? 


6.4.3.1.2.1.1 [8] 


M 
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Table A.45: Kerberos request support by the E-MTA 



Item 


Requirement 


Reference 


Status 


Support 


SEC_75 


Does the E-MTA implement only the fields 
specified in clause 6.5.5 [8] for the Kerberos 
request [KRB AP REQ]? 


6.5.5 [8] 


M 




SEC_76 


Does the E-MTA implement the 
KRB AP REQ with only the 
MUTUAL-REQUIRED option? 


6.5.5 [8] 


M 




SEC_77 


Does the E-MTA client verify that the 
authenticator Kerberos etype value is 
des3-cbc-md5? 


6.5.5 [8] 


M 




SEC_78 


Does the E-MTA client fully support the timing 
related Kerberos error code [KRB-ERROR] as 
specified in clause 6.5.5.2 [8]? 


6.5.5.2 [8] 


M 




Comments: 



Table A.46: Support of Fully Qualified Domain Names (FQDNs) by the E-MTA 



Item 


Requirement 


Reference 


Status 


Support 


SEC_79 


Does the E-MTA client query KDC FQDNs for 
a particular realm name using DNS SRV 
records, as specified in annex E of 
TS101 909-11 [8]? 


6.4.6.2 [8] 


M 




SEC_80 


Is the MTA principal name formatted as type 
NT-SRV-HST and as specified in 
clause 6.4.7 of TS 1 01 909-1 1 [8]? 


6.4.7 [8] 


M 




SEC_81 


Is the MTA FQDN Request formatted as 
specified in Table 6, clause 6.4.8.1 of 
TS101 909-11 [8]? 


6.4.8.1 [8] 


M 




SEC_82 


Is the MTA FQDN Request parameter 
"MUTUAL-REQUIRED - mutual 
authentication required" always set? 


6.4.8.1 [8] 


M 




SEC_83 


Does the E-MTA implementation of MTA 
FQDN Request comply with the parameters 
as specified in clause 6.4.8.1 of 
TS101 909-11 [8]? 


6.4.8.1 [8] 


M 




SEC_84 


Is the MTA FQDN Reply formatted as 
specified in clause 6.4.8.2, table 8 of 
TS101 909-11 [8]? 


6.4.8.2 [8] 


M 




SEC_85 


Does the E-MTA implementation of MTA 
FQDN Reply comply with the parameters as 
specified in clause 6.4.8.2 of 
TS101 909-11 [8]? 


6.4.8.1 [8] 


M 




SEC_86 


Does the Application Server (AS) Request 
sent by the MTA include the 
PROV-SRV-LOCATIONpre-authenticator 
that the KDC can use to locate the 
Provisioning Server? 


6.4.8.4 [8] 


M 




SEC_87 


Does the E-MTA specify the pre-authenticator 
type as -1 ? 


6.4.8.4 [8] 


M 
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Table A.47: Kerberized IPSec support by the E-MTA 



Item 


Requirement 


Reference 


Status 


Support 


SEC_88 


Does the E-MTA client support the 
mechanisms for the Kerberized key 
management profile specific to IPSec ESP in 
transport mode as specified in clause 6.5.6 of 
TS101 909-11 [8]? 


6.5.6 [8] 


M 




SEC_89 


Does the E-MTA client support the 
procedures for deriving the IPSec keys from 
the Kerberos subkey as specified in 
clause 6.5.6.1 ofTS 101 909-11 [8]? 


6.5.6.1 [8] 


M 




SEC_90 


Does the E-MTA client handle the periodic 
re-establishment of IPSec Associations as 
specified in clause 6.5.6.2 of 
TS101 909-11 [8]? 


6.5.6.2 [8] 


M 




SEC_91 


Does the E-MTA client handle the expiration 
of IPSec Security Associations as specified in 
clause 6.5.6.3 of TS 1 01 909-1 1 [8]? 


6.5.6.3 [8] 


M 




SEC_92 


Does the Client ignore IP packets from the 
Application Server received with an 
unrecognized IPSec Security Association? 


6.5.6.5.2 [8] 


M 




SEC_93 


Does the eMTA client at the key management 
layer follow the recovery steps as given in 
clause 6.5.6.5.3 of TS 101 909-1 1 [8] when 
the application server loses an outgoing 
IPSec SA ? 


6.5.6.5.2 [8] 


M 




Comments: 



Table A.48: Kerberized SNMP v3 support by the E-MTA 



Item 


Requirement 


Reference 


Status 


Support 


SEC_94 


Does the E-MTA support the Kerberized key 
management profile specific to SNMPv3 as 
given in clause 6.5.7 of TS 1 01 909-1 1 [8] ? 


6.5.7 [8] 


M 




SEC_95 


Does the E-MTA ensure that the 
Application-specific data field in the AP Reply 
management message is set to the 
concatenation as given in Table 12, 
clause 6.5.7 of TS 1 01 909-1 1 [8]. 


6.5.7 [8] 


M 




SEC_96 


When the SNMPv3 keys are lost does the 
E-MTA ensure the recovery steps given in 
clause 6.5.7.5 of TS 101 909-1 1 [8] are 
followed for re-establishment 


6.5.7.5 [8] 


M 
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Table A.49: End-to-end security support for RTP and RTCP 



Item 


Requirement 


Reference 


Status 


Support 


SEC_97 


Does the E-MTA ensure that the RTP_AES 
Transform ID is supported? 


6.6 [8] 


M 




SEC_98 


Does the E-MTA ensure that the 
Authentication Algorithm AUTHNULL is 
supported? 


6.6 [8] 


M 




SEC_99 


Does the E-MTA ensure that the 
Authentication Algorithm RTP_MMH_2 is 
supported? 


6.6 [8] 


M 




SEC_1 00 


Does the E-MTA ensure that the 
Authentication Algorithm RTP_MMH_4 is 
supported? 


6.6 [8] 


M 




SECJ01 


Does the E-MTA ensure that the AES-CBC 
Transform ID is supported? 


6.7 [8] 


M 




Comments: 



Table A.50: Device Provisioning 



Item 


Requirement 


Reference 


Status 


Support 


SEC_1 02 


When an MTA device is inserted into a 
network and does not have an association 
with the billing record does it still support a 
minimal voice communication service? 


7.1.1 [8] 


O 




SEC_1 03 


During the creation of an E-MTA configuration 
file, if the pktcMtaDevConfigKey is set, then 
does the MTA use this key to decrypt the 
configuration file? 


7.1.1.2.2 [8] 


M 




SEC_1 04 


During the creation of an E-MTA configuration 
file, if the pktcMtaDevConfigKey is set and the 
MTA does not use this key to decrypt the 
configuration file, does it assume the file is 
not encrypted? 


7.1.1.2.2 [8] 


M 




SECJ05 


Does the E-MTA ensure the configuration file 
is re-encrypted and TFTP server directory 
updated with the new file as given in 
clause 7.1.1.2.2 of TS 101 909-11 [8]? 


7.1.1.2.2 [8] 


M 




Comments: 



Table A.51 : Security call flows supported by the E-MTA 



Item 


Requirement 


Reference 


Status 


Support 


SECJ06 


Does the E-MTA ensure the security flows as 
specified in clause 7.1 .1 .2.5 of 
TS 101 909-1 1 [8] are performed immediately 
following the provisioning process? 


7.1.1.2.5 [8] 


M 




SECJ07 


Does the E-MTA obtain multiple Kerberos 
Tickets in the event that different MTA ports 
are configured for a different group of CMSs 
or other application servers? 


7.1.1.2.5.1 [8] 


M 




Comments: 
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Table A.52: Cryptographic mechanisms supported by the E-MTA 



Item 


Requirement 


Reference 


Status 


Support 


SEC_1 08 


Does the E-MTA ensure that the IPSec ESP 
is used to secure the MTA-CMS interface? 


7.4.1.3 [8] 


M 




SECJ09 


Does the E-MTA ensure that the IPSec keys 
are derived using mechanisms as specified in 
clause 6.5.6 of TS 1 01 909-1 1 [8]? 


7.4.1.3 [8] 


M 




SECJ10 


Does the E-MTA support the cryptographic 
mechanisms as specified in clause 7.6.2 of 
TS101 909-11 [8]? 


7.6.2 [8] 


M 




Comments: 



Table A.53: Generic structure of IPCablecom certificates 



Item 


Requirement 


Reference 


Status 


Support 


SEC_1 1 1 


Does the E-MTA implement version 3 of the 
X.509 certificates? 


8.1.1 [8] 


M 




SECJ12 


Do the certificates comply with 
RFC 2459 [14]? 


8.1.1 [8] 


M 




SECJ13 


Does the E-MTA implement the public key 
type OID as 1 .2.840.1 1 3549.1 .1 .1 ? 


8.1.2 [8] 


M 




SECJ14 


Does the E-MTA implement the public 
exponent for all RSA IPCablecom keys as 
F4-65537? 


8.1.2 [8] 


M 




SECJ15 


Does the E-MTA implement the root 
certificate as part of a certificate chain 
containing the MTA Root Certificate, MTA 
Manufacturer Certificate and the MTA Device 
Certificate? 


8.2.2.1 [8] 


M 




SEC_1 1 6 


Does the E-MTA implement the manufacturer 
certificate as part of a certificate chain 
containing the MTA Root Certificate, MTA 
Manufacturer Certificate and the MTA Device 
Certificate? 


8.2.2.2 [8] 


M 




SECJ17 


Is the manufacturer certificate included in the 
MTA secure code download? 


8.2.2.2 [8] 


M 




SECJ18 


Does the E-MTA support the IPCablecom 
telephony certificate hierarchy as given in 
clause 8.2.3 [8] 


8.2.3 [8] 


M 




Comments: 
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